Digital rights management

ABSTRACT

The present invention is generally in the field of digital rights management (DRM).

[0001] In one aspect, the present invention relates to a DRM “bureau”server which can, according to the embodiment, be used in many differentways. In one particular embodiment, the present invention relates to asystem that distributes the storage of rights and/or the rightsmanagement decision making process between a DRM client and a DRMserver, in order to overcome the shortcomings inherent in exclusivelyclient-side or exclusively server-side DRM systems. In anotherembodiment, the present invention relates to a system which managesrights to content on behalf of plural publishers.

[0002] If there is to be a viable commerce based upon the electronicdistribution of valuable multimedia content (such as for examplereports, images, music tracks, videos, etc.), then there must be somemeans of enforcing and retaining copyright control over the electroniccontent. There is now emerging a set of hardware and software solutions,generically known as digital rights management (DRM) solutions, that aimto provide this copyright control while, to a varying degree, alsoenabling new commercial methods suited to the Internet and electronicdelivery. Common to virtually all these solutions is the requirementthat the multimedia content be distributed within a persistenttamperproof encryption wrapper (the idea being that a million copies ofencrypted content is no more valuable than one). Very simply, DRM worksby carefully providing the consumers of this encrypted content withsecret decryption keys that provide temporary access to the content forsome controlled purpose, e.g. viewing, printing, playing, etc., withoutever providing access to the raw decrypted content that could be usedfor unauthorised reuse or redistribution.

[0003]FIG. 1 illustrates schematically an overview of how typical DRMsystems work. Referring to FIG. 1, a “publisher” of digital contentseals their digital content, buffers or streams within a layer ofencryption and digital signatures into a DRM-encrypted content format102. The encryption makes it difficult for malicious consumers to obtainaccess to the raw decrypted content (and make unauthorised copies forredistribution). The digital signatures prevent malicious consumers fromtampering with the encrypted content (perhaps to pass off the content astheir own) by enabling the DRM system to detect the smallest change tothe encrypted content. The DRM-encrypted content 102 can then bedelivered to consumers via any electronic distribution medium 104, e.g.Web, ftp, e-mail, CD-ROM, etc. The publisher need not worry aboutprotecting the DRM-encrypted content 102 in transit to the consumersince it is inherently protected by its encryption layer and digitalsignatures.

[0004] Less sophisticated DRM systems sometimes bundle individualconsumer access rights with the content, either within the encryptionlayer or at least protected by the digital signatures. The advantage ofbundling rights with the content is that the consumer can obtain boththe content and the rights at the same time. Disadvantages includeextreme inflexibility in the rights management policies that can beimplemented and an enormous versioning problem (since there needs to bea separate version of the encrypted content 102 for each consumer and anew version of the encrypted content whenever the rights change).

[0005] More sophisticated DRM systems deliver the rights separately fromthe content (from a DRM server 108). The rights are encoded in someelectronic format 110 (i.e. electronic “rights”) and specify thepermitted relationship between consumers and DRM-encrypted content sets(and subsets), e.g. which content the consumer can access, what they arepermitted to do with it (e.g. printing), and for how long.

[0006] A specialised viewer (the DRM client 106) resident on theconsumer device is required to obtain, manage and interpret the rights,temporarily decrypt the encrypted content and view/play it within asecure environment (so that the consumer cannot obtain access to the rawdecrypted content or the decryption keys) subject to the restrictionsimplied by the consumer's rights (e.g. view but do not print adocument). The DRM server 108 is responsible for issuing rights torequesting DRM clients 106. Current DRM systems typically issue rightsto authenticated consumers at the time of purchase (or grant) and therights are transferred to permanent storage on the consumer device 106.The DRM server 108 plays no further role in the ongoing use of thoserights.

[0007] In general, “content sets” can be thought of as a related set ofone or more digital content, buffers or streams. In general, “rights”can be thought of as an electronic description (explicit or byimplication) of the association between consumers (or consumer devices)and DRM-protected content sets. Rights can optionally specify means ofidentifying the consumer (or consumer device) to which the rights‘belong’; means of identifying the content sets and subsets to which therights apply; encryption keys and checksums (cryptographic orotherwise); and, the specific access rights granted to the consumers(and/or their consumer devices) over those content sets (e.g. whether ornot the consumer can print a document, the duration of access, etc.).Rights can be encoded in any machine-readable form (e.g. parsablelanguages, specialised data structures, etc.) and are used internally bythe DRM system to grant, deny or meter consumer access to encryptedcontent. In general, “node locks” can be thought of as rights that aretied to a particular consumer device or “node”, i.e. rights that willonly provide access to DRM-encrypted content on one particular consumerdevice.

[0008] It is preferable for a DRM system to issue rights to a consumerfor the shortest possible time: the rights are preferably issued at thetime the consumer actually attempts to access the encrypted content andpreferably removed from the consumer device as soon thereafter aspossible. In preferred implementations, this requires that the rightsare stored on a remote server hosted on a network (e.g., the Internet oran intranet). The consumer identifies herself to the local DRM systemthat transparently opens network connections to the remote server toobtain the rights which are then used to decrypt and access theencrypted content.

[0009] It is useful to examine the historical progression of digitalrights management. Digital rights management has historically proceededfrom off-line contractual agreements, to server-side rights managementsystems, and then to client-side rights management systems.

[0010] With off-line contractual agreements (which in practice provideno rights management at all), a publisher requires its content consumersto accept a legally binding agreement governing the use of thepublisher's digital content before the consumer is provided with thedigital content. The difficulty of detecting subsequent abuse (i.e.unauthorised duplication and redistribution), the scale and ease withwhich net-enabled consumers can now abuse that content, and thepractical difficulties of taking legal action against thousands ofnon-compliant consumers, many of whom may be in different legaljurisdictions, means that off-line contractual agreements areincreasingly only useful as a backup to technological means of enforcingcopyright and use rights.

[0011] Next in the progression of rights management is server-sidedigital rights management. An overview of server-side digital rightsmanagement is illustrated schematically in FIG. 4. A publisher providescontrolled access to its digital content 204 via one or more centralisedservers 202 (e.g. Web servers). A consumer 210 connects via a network212 (such as the Internet) to the publisher's servers 202 to locate,download and view digital content 204. Typically, the consumer 210 mustprovide a username and password to an authentication mechanism 214 thathas been issued to the consumer by the server-side rights managementsystem running on the publisher server 202. The basic idea is thatunauthorised consumers cannot download content from the publisher'sserver(s) to which the publisher has not granted them access. Manypublishers have spent millions of dollars developing sophisticatedserver-side content repositories capable of providing fine-grainedcontrol over which digital content files/buffers can be served toidentified consumers.

[0012] Unfortunately, server-side rights management suffers from anumber of fundamental shortcomings that render it relatively ineffectivein practice. First, almost all the Internet protocols by which consumersdownload or otherwise obtain digital content from publishers requirethat the content be transmitted to the consumer's device in open andstandard formats (such as HTML, PDF, MP3, etc.) so that the consumer'sdevice can render/play that content without requiring a specialisedviewer/player for each publisher's content. This means that once theconsumer has identified themselves to the publisher and obtained thecontent, nothing prevents that consumer from redistributing that content(such illicitly redistributed content is designated by reference numeral216 in FIG. 4) to another consumer 220. What this means is that thepublisher has completely lost control over its content.

[0013] Furthermore, nothing prevents the consumer 210 from sharing theirauthentication details (e.g. username and password) 218 with anotherconsumer 220 who can then impersonate the original consumer 210 andobtain access to the publisher's content free of charge. In fact, thispractice is very common. The relatively poor logging informationavailable to the publisher's server 202 (e.g., the difficulty ofdistinguishing between client IP addresses and firewall IP addresses)makes it extremely difficult to detect this form of abuse.

[0014] In addition, because server-side rights management by definitionexerts no control over what happens to the content once it reaches theclient-side, server-side rights management cannot be used to manageinherently client-side rights, such as whether or not a consumer isallowed to print a document.

[0015] The requirement for publishers to retain control over theircontent after it has left their server/site led to the development ofclient-side rights management systems (e.g. the DRM solution embedded inearly versions of Microsoft's Windows Media Player). FIG. 3 illustratesschematically an overview of a purely client-side rights managementsystem. In particular, client-side rights management systems generallyuse some form of encryption to convert digital content into an encryptedform 304 that is not immediately useful to a consumer 310 (so thatunauthorised redistribution of the encrypted content by a consumer 310to another consumer 320 is no longer a problem). In order for theauthorised consumer 310 to obtain access to the useful, decryptedcontent they are issued with the decryption keys 306, usually in returnfor payment. Considerable effort is devoted by client-side rightsmanagement systems to prevent the consumer from directly accessingeither the decryption keys 306 or the decrypted content (either of whichwould enable the authorised consumer 310 to bypass the client-sidesecurity and redistribute the decrypted content to another consumer320). In addition to decrypting the content, the client-side rightsmanagement can often also enforce various access policies such aslocking the content to a specific consumer device (“node-locking”),expiring access to the content after a certain time, etc.

[0016] This approach is known as client-side rights management since: itrequires the presence of specialised client-side hardware or software(i.e. hardware or software installed on the consumer's computer,designated generically in FIG. 3 as “DRM client 312”) to perform thetemporary client-side decryption and to provide a secure viewingenvironment on device of an authorised consumer 310 without exposing thedecrypted content or the decryption keys to the consumer; the rights(i.e. what the consumer 310 is entitled to do with the encryptedcontent) are kept in storage 314 at the client-side (i.e. on theconsumer's computer); the rights management decisions (i.e. what theconsumer is allowed to do with the encrypted content) are takenexclusively at the client-side 310 (as they must be, given that this iswhere the rights reside).

[0017] Whilst client-side rights management is a significant improvementover server-side rights management, it still suffers from a number ofserious drawbacks. For example, storing rights on the client makes itthe consumer's responsibility to maintain those rights (and protect themagainst loss). As a result, it is the consumer's problem when thoserights are lost (for example due to a catastrophic failure of theconsumer's device). When one imagines the consequences of losing rightsthat may have been progressively acquired over a long period, and whenone also reflects on the relative unreliability and short lifetimes ofmodern computing devices, this shortcoming by itself makes purelyclient-side rights management systems impracticable. In fact,client-side rights management systems appear to be little more than aresurgence of old personal computer software “copy-lock” technologiesapplied to digital content. Personal computer software copy-lockingfailed at least in part because of the burden of responsibility placedon the consumer to maintain their “copy locks”. It is also significantthat client-side rights management systems are often explicitly designedto make it difficult to archive and restore rights since archivingcopies of rights and restoring them from archive when the originalrights have expired is the most obvious way of attacking client-siderights management systems.

[0018] In addition, rights management decisions taken exclusively at theclient-side are necessarily restricted to those decisions that can betaken within the immediate context of the client, based on what is knownlocally at the client. In practice, very little is reliably known at thelocal client. This dramatically restricts the rights managementdecisions that can be taken. For example, the local computer clock iseasily tampered with so the DRM client has little reliable knowledge ofthe time and therefore has limited ability to faithfully implement starttimes and stop times. Furthermore, the local client is completelyunaware of what other consumers are doing, thus making concurrent usagerestrictions impracticable.

[0019] The local computer is even completely unaware of othercomputers/devices being used by the consumer, making it impossible toeffectively manage the “roaming” of rights across multiple devices.Thus, storing rights on the client means that consumers must purchaserights separately for each computer on which they desire to accesscontent. This runs counter to consumer expectations. By analogy,consumers do not typically purchase a book to read at work and anothercopy to read at home. This also runs counter to the increasinglymobility of computer users, with consumers using increasinglyinterchangeable net-enabled computers to access content and servicesover an increasingly pervasive global network.

[0020] According to a first aspect of the present invention, there isprovided a system for managing a consumer's access to content to berendered by a DRM client of the consumer, the system comprising:

[0021] a DRM server for engaging in a transaction with a consumer DRMclient such that the transaction results in the consumer being grantedat least one right to the content, the DRM server being arranged suchthat the at least one right is stored at the DRM server and the DRMserver checks out a copy of the at least one right to a said consumerDRM client.

[0022] Amongst other things, this aspect of the invention providesconsumers with the facility easily to recover a copy of the rights inthe case of a failure of a consumer device on which the (initial copy ofthe) rights was stored.

[0023] The DRM server may include a storage device and is arranged tostore the at least one right in the storage device and to allow the atLeast one right to reside in the storage device for a predetermined timebefore being made void. The DRM server may be arranged to void the atleast one right by removing the at least one right from the storagedevice.

[0024] The DRM server may be arranged so that the copy of the at leastone right checked out to a said consumer DRM client is not identical tothe at least one right stored on the DRM server. For example, thechecked-out copy may include an expiry time, which in general isrelevant to that client only.

[0025] The DRM server may be arranged to check out a further copy of theat least one right to a said consumer DRM client in the event that theor an earlier copy of said at least one right is lost or otherwiseinaccessible to a said consumer DRM client.

[0026] According to a second aspect of the present invention, there isprovided a system for managing a consumer's access to content to berendered on a consumer content rendering device, the consumer contentrendering device including a storage device, and wherein a DRM server isarranged to provide a copy of at least one right to the consumer contentrendering device for storage in the storage device, the systemcomprising:

[0027] a DRM client on a consumer content rendering device that isarranged to attempt initially to retrieve a copy of at least one rightfrom a storage device of the consumer content rendering device, and, inthe event that a copy of the at least one right is not found in thestorage device, to attempt to retrieve a copy of the at least one rightfrom a said DRM server.

[0028] The DRM client may be arranged to allow a copy of the at leastone right to reside in the storage device for a predetermined timebefore being made void. The DRM client may be arranged to void the atleast one right by removing the copy of the at least one right from thestorage device.

[0029] The DRM client may be arranged to allow the consumer to configurethe predetermined time. This allows the user to shorten the time bywhich the right is voided, allowing the user more quickly to obtain theright next time if necessary or desired.

[0030] According to a third aspect of the present invention, there isprovided a system for making rights management decisions relating toaccess to content, the system comprising:

[0031] a DRM server for making a first rights management decision basedon a request from a DRM client for a right to access content and forresponding to the request accordingly such that a said DRM client canmake a second rights management decision based on the response from theDRM server.

[0032] As is discussed further below, such a distribution of themanagement making decisions enables many features which were simply notpossible in prior art DRM systems which were in essence exclusivelyclient-side or exclusively server-side.

[0033] The DRM server may be arranged so that the first rightsmanagement decision includes the DRM server refusing to grant a said DRMclient the right to access the content on the basis that granting theright would cause a concurrent consumer limit to be exceeded.

[0034] The DRM server may be arranged so that the first distributedrights management decision includes granting the right to access thecontent on a plurality of devices.

[0035] The DRM server may be arranged so that the first distributedrights management decision includes limiting the number of devices thatcan be used to access the content.

[0036] The DRM server may be arranged to modify at least one individualright specification based upon at least one item of consumer informationreceived from a DRM client.

[0037] The DRM server may be arranged to store a group rightspecification for at least one consumer of a group of consumers and tomake a rights management decision based on the group rightspecification.

[0038] The DRM server may be arranged to modify at least one individualright specification associated with a first publisher based upon atleast one transaction associated with a second publisher.

[0039] According to another aspect of the present invention, there isprovided a system for making rights management decisions for content,the system comprising:

[0040] a DRM client that is arranged to request from a DRM server aright to access content and to receive from a said DRM server the resultof a first rights management decision made at the DRM server,

[0041] the DRM client further being arranged to make a second rightsmanagement decision based on a said result received from a said DRMserver.

[0042] The DRM client may be arranged so that the second rightsmanagement decision includes determining whether the DRM client has aright to print the content. Alternatively or additionally, the DRMclient is arranged so that the second rights management decisionincludes determining whether the DRM client has a right to save thecontent to a storage device.

[0043] According to another aspect of the present invention, there isprovided a system for logging access to content by one or moreconsumers, the system comprising:

[0044] a DRM server that is arranged to log requests for access tocontent to produce a first log record and to receive from at least oneDRM client a second log record of access to the content.

[0045] The DRM server may be arranged to merge the first log record andthe second log record.

[0046] According to another aspect of the present invention, there isprovided a consumer DRM client arranged to log access to content by theDRM client to produce a log record, the DRM client further beingarranged to transmit the log record to a DRM server.

[0047] The DRM client may be arranged to temporarily cache the logrecord and to send the log record to a said DRM server after apredetermined period of time.

[0048] According to another aspect of the present invention, there isprovided a system for obtaining from a DRM server a right to accesscontent on a consumer device, the right to access the content beingstored in both the consumer device and the DRM server, the systemcomprising:

[0049] a DRM client; and,

[0050] a consumer device with which the DRM client is associated;

[0051] the DRM client being arranged first to attempt to retrieve theright from the consumer device and then, if unable to retrieve the rightfrom the consumer device, to attempt to retrieve the right from a saidDRM server.

[0052] The consumer device may have both persistent storage andnon-persistent storage, the DRM client preferably being arranged toattempt to retrieve the right in the following order:

[0053] from the non-persistent storage of the consumer device, and then,if the right cannot be retrieved from the non-persistent storage of theconsumer device, from the persistent storage of the consumer device, andthen, if the right cannot be retrieved from the persistent storage ofthe consumer device, from a said DRM server.

[0054] According to yet another aspect of the present invention, thereis provided a system for managing rights to content, the systemcomprising:

[0055] a DRM server that is arranged to handle rights management onbehalf of a plurality of content publishers and to issue rights to oneor more consumers accordingly.

[0056] The DRM server may be arranged to participate in rightsmanagement decisions in cooperation with a client-side DRM system.

[0057] The DRM server may be arranged to issue rights to DRM-protectedcontent without which access to the said DRM-protected content isprecluded.

[0058] The DRM server may be arranged to maintain accounts for consumersinto which the plurality of content publishers can depositconsumer-specific rights.

[0059] The DRM server may be arranged to require that a consumer providea consumer identification in order to download a right to accesscontent.

[0060] The DRM server may be arranged to implement cross-consumer rightsmanagement policies. For example, the cross-consumer rights managementpolicies may include rewarding first consumers for recommending secondconsumers to access DRM-protected content by granting the firstconsumers additional rights.

[0061] The DRM server may be arranged to implement cross-publisherrights management policies. For example, the cross-publisher rightsmanagement policies may include one publisher granting the consumersrights to another publisher's content as part of a promotion.

[0062] The DRM server may be arranged to permit at least one consumer toroam between at least two consumer devices and to ensure that said atleast one consumer can only simultaneously access the content on alimited number of the at least two consumer devices.

[0063] The DRM server may be arranged to deliver a copy of a right to aconsumer whilst retaining a copy of the right in storage.

[0064] According to a further aspect of the present invention, there isprovided a system for providing rights to content to consumers, thesystem comprising:

[0065] a server that is arranged to provide a network-accessibleinterface that is arranged to enable publishers of content to create andconfigure rights templates that can be subsequently purchased by orgranted to consumers as rights instances.

[0066] The server may be arranged to provide consumer accounts in whichthe rights instances can be stored.

[0067] According to a further aspect of the present invention, there isprovided a system for providing rights to content to consumers, thesystem comprising:

[0068] a DRM server that is arranged to calculate a charge for apublisher based upon the number of consumers holding rights to contentfrom the publisher on the DRM server.

[0069] The DRM server may be arranged to redetermine the charge atpredetermined intervals.

[0070] According to a further aspect of the present invention, there isprovided a system for providing rights to content of a publisher toconsumers, the system comprising:

[0071] a DRM server that is arranged to calculate a charge for apublisher based upon the loading imposed on the DRM server by consumersholding the rights to content of said publisher.

[0072] The charge may be based on the number of individual accesses tothe DRM server resulting from the consumers accessing content of saidpublisher.

[0073] According to a further aspect of the present invention, there isprovided a system for providing rights to content of a publisher toconsumers, the system comprising:

[0074] a DRM server that is arranged to calculate a charge for apublisher based upon the volume of the rights maintained on the DRMserver on behalf of consumers holding the rights to content of thepublisher.

[0075] The volume of the rights may be determined in accordance with thetime that the DRM server holds said rights.

[0076] According to a further aspect of the present invention, there isprovided a system for providing rights to content of a publisher toconsumers, the system comprising:

[0077] a DRM server that is arranged to calculate a charge for apublisher based upon a percentage of the value of rights associated withcontent produced by the publisher and maintained by the DRM server.

[0078] According to another aspect of the present invention, there isprovided a DRM client for obtaining access rights to DRM encryptedcontent and decrypting the content, the DRM client also being capable ofencrypting content.

[0079] This enables any consumer of DRM-protected content to be apublisher of DRM-protected content.

[0080] The DRM client is preferably capable of adding a digitalsignature to content encrypted by the DRM client.

[0081] According to another aspect of the present invention, there isprovided in combination, at least two DRM servers with a gatewaytherebetween, wherein one of the DRM servers is arranged to hold anaccount on behalf of a consumer and to allow said consumer to accessDRM-protected content whose rights are controlled by the other of saidDRM servers via the gateway.

[0082] In an embodiment, consumers can access content controlled bycentralised digital rights management servers on which they do notdirectly hold consumer accounts by authenticating themselves via agateway to the centralised digital rights management server on whichthey hold their primary consumer account.

[0083] The gateway between the at least two DRM servers may be operatedsubject to cross-charging relationships between the operators of the DRMservers.

[0084] The one of the DRM servers that holds an account for a consumermay be arranged to forward consolidated usage reports, consolidatedstatements and consolidated billing to said consumer based on totalaccess to the DRM servers by the consumer.

[0085] Embodiments of the present invention will now be described by wayof example with reference to the accompanying drawings, in which:

[0086]FIG. 1 illustrates schematically an overview of how typical DRMservices work;

[0087]FIG. 2 illustrates schematically an overview of conventionalserver-side DRM;

[0088]FIG. 3 illustrates schematically an overview of conventionalclient-side DRM;

[0089]FIG. 4 illustrates schematically an example of a system ofprogressive caching for distributed DRM;

[0090]FIG. 5 illustrates schematically examples of various scenarios forusing the FIG. 4 system;

[0091]FIG. 6 illustrates schematically an example of a system fordistributed rights logging;

[0092]FIG. 7 illustrates schematically basic DRM service bureau conceptsrelating to an embodiment of the present invention;

[0093]FIG. 8 illustrates schematically an example of a DRM bureauservice acting as a “rights” bank;

[0094]FIG. 9 illustrates schematically an example of a DRM bureauservice acting as a rights boutique;

[0095]FIG. 10 illustrates schematically an example of a DRM bureauservice system that is usable for personal DRM-encryption;

[0096]FIG. 11 illustrates schematically an example of load-based pricingfor use of a DRM bureau service;

[0097]FIG. 12 illustrates schematically an example of revenue-basedpricing for use of a DRM bureau service;

[0098]FIG. 13 illustrates schematically an example of revenue-basedpricing, with a load-based floor, for use of a DRM bureau service;

[0099]FIG. 14 illustrates schematically an example of a logging basedbureau affiliate program; and,

[0100]FIG. 15 illustrates schematically an example of “roaming” betweenDRM bureaux,

“BUREAU CONCEPT” GENERALLY

[0101] In accordance with an embodiment of the present invention, ingeneral terms an organisation (or application service provider, ASP),which typically will be centralised, operates one or more DRM servers onbehalf of one or more publishers and/or one or more consumers. Thisservice is hereafter generally referred to as a “DRM bureau service”. Aswill be appreciated, “publishers” may also be “consumers”. In someembodiments, the organisation may be a publisher.

[0102] Distribution of Rights Storage

[0103] Referring to FIG. 4, distribution of rights storage andprogressive rights caching will first be discussed. Bearing in mindthat, in the preferred embodiment of digital rights management (DRM)operated in accordance or in conjunction with the present invention,there is a complete separation between the rights themselves and the(encrypted) content, in accordance with an embodiment of the presentinvention illustrated schematically in FIG. 4, the storage of rights isdistributed between the client and a remote server (or set of servers)within a series of progressive caches. This allows optimisation of theuse of network bandwidth and also provides other advantages as will bediscussed further below, including for example the provision foroff-line access to the content, sharing of rights between multipleprocesses on the client device, etc. Separately, a flexible structure ofrights management policies may be implemented.

[0104] In FIG. 4, encrypted content 402 is provided from a contentserver 404 via a network 406 to a consumer device 408 that “executes”(via hardware or software, or a combination of both) a DRM client 410.That is, the DRM client 410 temporarily decrypts the DRM-encryptedcontent in a secure viewing/playback environment. The DRM client 410interprets and implements the specified rights and manages theclient-side elements of the progressive rights caching. In addition, acooperating server-side rights management component, the DRM server 412,is provided. Client-side rights management typically pertains to localclient-side activities, such as printing or saving DRM-protectedcontent, while server-side rights management typically pertains to moreglobal issues such as concurrency (the number of simultaneous accessesto DRM-protected content), control over the number of devices on which aconsumer is allowed to access DRM-protected content, implementation ofsubscription models where one rights specification applies to multipleitems of DRM-protected content, etc.

[0105] Rights originate from some server remote to the client (in FIG.4, rights 414 originate from the DRM server 412) and are ultimatelyapplied to content 402 downloaded to the client 408. That is, if thereis to be any rights management decisions to be taken at the client, therights must also travel to the client. However, in moving between theserver and the client, the rights 414 are stored for arbitrary periodsin a number of caches.

[0106] For example, one cache may be an in-memory cache 452 in thememory of the client-side device 408. The in-memory cache 452 mayactually be a collection of various caches structured to facilitatesharing and control over client-side rights (e.g. global caches,per-process caches, per-viewer caches, per-thread caches, per-fibrecaches, etc.).

[0107] Another cache may be in persistent storage 454 closely associatedwith the client-side device 408 (e.g. on a hard disk, removable disk,non-volatile memory, etc.)

[0108] Another cache may be in the temporary or persistent storage of adevice permanently or temporarily attached to the client-side device(e.g. mobile telephone, PDA, smart card, etc.).

[0109] Yet another cache may be in temporary or persistent storage 456on a remote net-accessible server (which does not imply a need for apermanent connection)

[0110] In order to implement various rights management policies, aclient-side rights management component (which may be, but need not be,part of the DRM client 410) can search through these caches 452, 454,456 in various orders for rights pertaining to a particular piece ofDRM-encrypted content 402. In a typical embodiment, the client-side DRMcomponent searches first in various in-memory caches 452 and then, ifsuitable rights are not found, it searches through various on-diskcaches 454. If suitable rights are not found there, the client-side DRMcomponent requests the rights from a remote DRM server 412 (acting as anetwork-accessible cache 456). The order of search is not limited tothat set forth in this example. Different search orders may be requiredto implement different rights management policies.

[0111] Advantages of distributing the rights storage between the clientand server, and implementing the described progressive cachingmechanism, include: (i) protection against the loss of valuable rightsdue to the catastrophic failure of individual caches, e.g. anapplication process crashing and losing an in-memory cache as the clientmay be able quickly to obtain a copy of the rights locally from anon-disk cache for example, or a computer crashing and losing itsin-memory and on-disk caches as the client may be able to obtain a copyof the rights more rapidly from a server cache; (ii) enabling theimplementation of rights management policies that require distributeddecision making and therefore require distributed rights storage, e.g.restrictions on the number of concurrent consumers of a content set(which requires a centralised server-based view of all the consumers ofthat content set); and (iii) mobility of rights between distributedcaches enables mobility of consumer access to DRM-protected content. Forexample, rights can be “checked out” from the DRM server to aclient-side cache on a particular consumer device (i.e. a copy is sentto the client with a copy being retained by the server) and then“checked back in” to the DRM server in order for it to be checked outagain to a different consumer device. It should be appreciated that theright that is transferred to the client may not always be identical tothe copy that is retained by the server because, for example, thetransferred copy may include an expiry time relevant to that clientonly.

[0112] Distribution of Rights Management Decision Making

[0113] The actual rights management decision making process may bedistributed between the consumer device (i.e. the point of consumptionof digital content) and a rights management server (DRM server). Itshould be noted that conventional client-side DRM systems may sometimesappear to have a server component but these servers are restricted tosupporting the initial purchase of rights and subsequent receipt andconsolidation of client-side DRM log records. These servers do not playan active role in the ongoing rights management decision making process.

[0114] Distributing the rights management decision making processbetween the DRM client 410 and one or more centralised DRM servers 412represents a significant advance over purely server-side or purelyclient-side DRM systems, in which the rights management decisions aretaken either exclusively at the server-side or exclusively at theclient-side, and is an approach which is well suited to managing digitalcontent consumption over modern pervasive broadband networks.

[0115] Referring still to FIG. 4, distributed DRM employs intelligenthardware or software components active on both the client (DRM client410) and one or more remote servers (DRM servers 412). In a distributedDRM system, the DRM client 410 associated with a consumer device and theDRM server 412 cooperate to arrive at a decision over whether aparticular consumer on the consumer device can access a particular pieceof DRM-protected content. This cooperation can involve communicationbetween the DRM client and the DRM server and this communication mayinvolve the exchange of rights encoded in electronic form.

[0116] An example scenario of such cooperation is illustratedschematically in FIG. 5. Referring to FIG. 5, a consumer attempts toaccess a DRM-encrypted content file that is subject to the rightsmanagement restriction that this file may only be simultaneouslyaccessed by up to a hundred consumers. The DRM client 502, 504 or 506checks its local client-side rights cache(s) for prior authorisation toaccess this DRM-encrypted content file. It could potentially findmatching rights in any of its in-memory caches or in any of its on-diskcaches, cached from an earlier request (and not necessarily for the samecontent file if the rights apply to multiple content files). If matchingrights are not found, the DRM client 502, 504, or 506 can forward itsrequest on to the remote DRM server 550. The DRM server 550 can look inits cache 552 for matching rights (for the identified consumer to accessthe DRM-encrypted content file) whilst also establishing whether theconcurrent use restriction would be exceeded, e.g. whether this is thehundred and first consumer currently attempting to access theDRM-encrypted content file. If matching rights are available and theconcurrent usage restriction is not being exceeded, the DRM server 550can grant the DRM client 502, 504 or 506 permission to proceed and(optionally) send the DRM client a local version of the electronicallyencoded rights for storage in the progressive client-side caches.

[0117] In the FIG. 5 example, the DRM client 502 already has the rightsin its client-side cache 503. The DRM client 504 obtains rights from thecache 552 of the remote server 550. The DRM client 506 cannot obtainrights from even the remote DRM server 550 because the concurrent usagerestrictions maintained at the DRM server 550 would be violated.

[0118] As another example, the DRM process is operated to provide arights management restriction whereby only a limited number of copies ofthe content can be printed by a user or users. Thus, a user iseffectively issued with a corresponding number of print rights, thoserights being stored on the DRM server 550. In use, the user issues aprint command (directly or indirectly) to the DRM client 506. As aresult, the DRM client 506 requests from the DRM server 550 the right toprint a copy of the content. The DRM server 550 decides whether or notthe user has the right to print the content and, if so, sends the rightelectronically to the DRM client 506. The DRM client 506 can then decidelocally whether or not it can actually print the document based on therights issued by the DRM server 550; in this example, this decisionmaking process at the DRM client 506 may include taking into account howmany copies of the content have already been printed by the DRM client506. Thus, in this example, the distribution of the rights managementmaking decision is (i) whether the user is to be permitted to print thecontent (decided at the DRM server 550) and (ii) the number of copiesthat can actually be printed (decided at the DRM client 506 based uponthe rights issued by the DRM server 550 and optionally taking intoaccount local conditions)

[0119] It will be appreciated that this second example can be applied byanalogy to many processes which take place only at the client side andabout which the DRM server may or will typically have no knowledge,including for example the saving of the content to a hard disk at theclient.

[0120] Thus, this distribution of the rights management decision makingprocess between cooperating hardware and/or software DRM components atthe client and server allows the implementation of rights managementpolicies that utilise knowledge outside the immediate context of eitherof the client or the server taken alone. An embodiment can providesupport for managing rights on a concurrent usage basis (e.g.restrictions on the number of concurrent consumer devices, consumers andgroups of consumers accessing a set of digital content). An embodimentcan provide support for managing rights across multiple consumer devices(e.g. allowing consumers to access DRM-protected on multiple devicesutilising rights stored on a centralised DRM server). Furthermore,support can be provided for coordinated management of rights acrossmultiple consumers, groups of consumers, content publishers, etc. Anexample of coordinated management of rights across multiple consumers isthe issuing of one consumer (additional) rights to access content inreturn for actions performed by that consumer, e.g. recommending afriend to purchase rights. An example of coordinated management ofrights across groups of consumers is the issuing of rights to a group ofconsumers (e.g. a department within a company). Consumers would bepermitted to access their rights by virtue of belonging to the consumergrouping. Revoking rights could be implementing by removing a givenconsumer from membership of a given consumer grouping. Concurrent usagerestrictions could be applied to a consumer grouping, e.g. allowing amaximum of 10 consumers within a given group access to a set of content.An example of coordinated management of rights across multiple contentpublishers is the issuing to consumers acquired by a first contentpublisher (i.e. consumers for whom an account was created on the DRMserver to store rights to content published by the first contentpublisher) with rights to sample content from another content publisher.

[0121] Information Logging

[0122] Since DRM systems closely manage the process of consumersaccessing DRM-protected digital content, the DRM systems are in a uniqueposition to gather information about consumer access patterns, e.g.which consumers are accessing the publisher's content, on which devices,at what time, for how long, whether they printed copies, etc.Consequently, most DRM systems log various amounts of usage-relatedinformation and attempt to route that logged information back to thepublisher. The publisher typically uses these logs (directly or via anintermediary) to construct reports for:

[0123] (i) billing—logged measurements of the use of DRM-protectedcontent can serve as the basis of usage-related billing systems andlogged financial transactions involved in the purchase or granting ofrights to consumers are required for billing purposes;

[0124] (ii) product “tuning”—detailed feedback on consumer accesspatterns enables publishers to adjust their content sets and theirrights management policies to better meet consumer demand; and, (iii)market research—detailed feedback on consumer access patterns is aphenomenally powerful means of conducting market research, e.g.profiling consumer preferences by market segment, country-of-consumption(if logged), correlation between the purchase of digital products fromdifferent market sectors, etc.

[0125] In accordance with the embodiment of the invention illustrated inFIG. 6, such information logging is performed in a distributed DRMenvironment. Since access to the content is via the DRM client 602hardware or software, the client 602 can log every aspect of theconsumer's access to DRM-protected content. This information mayinclude, for example: consumer identity; group identity (e.g. acorporate department to which the consumer belongs);point-of-consumption device identity (e.g. device IDs, networkaddresses, etc.); point-of-consumption device location (geographiclocale, time zone, etc.); DRM-protected content identity (e.g. thecontent sets and subsets to which a particular piece of content belongs,specific item identifiers, etc.); time and duration of access toDRM-protected content; time and duration of all DRM-related operations;use made of DRM-protected content, e.g. viewed, played, paused, printed,saved, etc.; and, success or failure of attempted operations, e.g. therefusal of a request to print a document.

[0126] In accordance with one embodiment, the logging of consumer accessactivities is directly to the DRM server 608 (for server-sideconsolidation with DRM log records 610 from other consumers or consumerdevices), while in other embodiments the logging information is cachedlocally on the consumer device 604 for later transmission to the DRMserver 608. DRM transactions that directly involve the DRM server 608(e.g. a client-side request for rights that are not already cached onthe client-side) can result in the immediate generation of DRM logrecords 612 at the server. When client-side log records 604 arrive atthe DRM server 608, they can be consolidated with pre-existing serverlog records 610 and sorted/collated by time stamp, publisher, consumer,etc.

[0127] Server-side consolidation of DRM log records from both the DRMclient 602 and the DRM server 608 provides a far more comprehensiverecord of what consumers are doing with DRM-protected content thaneither client-side logging or server-side logging can provide alone.Client-side logging is typically of activities that would otherwise beentirely unknown to a server-side logging mechanism and vice versa. Forexample, the logging associated with current server-side access controlsystems clearly does not record basic client-side activities such asprinting or saving of a DRM-protected document.

[0128] Client-side logs 604 can be transmitted to the DRM server 608(for consolidation with server-side DRM logs 610) in a number of ways.For example, in the presence of a suitable network connection (notnecessarily permanently held open) between the DRM client 602 and theDRM server 608, client-side log records can be sent immediately to theDRM server 608. Alternatively, in order to reduce traffic between theDRM client 602 and the DRM server 608, client-side log records 604 canbe cached in temporary or permanent local storage and batched up fortransmission either on a periodic or scheduled basis or after theexpiration of some “watchdog timer” set by the presence of newclient-side log records. As another example, the log record transmissioncan be “piggy-backed” onto some higher-priority traffic between the DRMclient and the DRM server. Some combination of the above techniques canbe used. For example, if a log record has not been “piggy-backed” withina watchdog period, then it can be sent independently.

[0129] If log records are being cached for later transmission, a limitmay be imposed on the number of records sent in an individual networktransaction with the DRM server, in order to reduce the load on thenetwork and on the DRM server.

[0130] In much the same way that content and rights are protected fromabuse while resident on the consumer device, cached client-side logrecords can be protected from tampering and deletion. This is achievedin some embodiments by, for example: using encryption and non-obviousstorage to obfuscate the log records; linking the survival of the logrecords to the ongoing survival of the consumer's access rights, i.e. ifa consumer manages to destroy their log records (perhaps attempting toavoid usage-related payment) they also prevent themselves from havingfurther access to the content; and associating log records with somepredictable sequence so that the absence of log records can be detected.

[0131] Servicing Plural Publishers/Consumers

[0132] In accordance with one embodiment, illustrated schematically inFIG. 7, a bureau service 702 appears in practice as a Web site at whichboth content publishers 704 and content consumers 710 can open accounts705 and 711 respectively. Content publishers 704 use their bureauaccounts 705 to DRM-encrypt 706 their digital content 708 in such a waythat consumers 710 must obtain rights 712 from the bureau before theycan access the DRM-encrypted content 708. Content consumers 710 usetheir bureau accounts 711 to purchase the rights 712 to access theDRM-encrypted content 708 (from one or more publishers) and canoptionally store their rights 712 on the bureau's DRM servers 702.

[0133] It should be noted that the bureau service 702 does not need tohost content 708 though in some embodiments the bureau service 702 doeshost some sample DRM-encrypted content. Publishers 704 can either hostthe DRM-encrypted content 708 on their own sites or out-source thehosting of DRM-encrypted content 708 to third party hosting services,content aggregators, portal sites, etc.

[0134] Behind the scenes, the bureau service operates a number of DRMservers. The bureau service 702 therefore acts as a centralisedrepository or “bank” for the digital rights 712, with DRM trafficflowing transparently through the bureau service 702 as consumers 710access DRM-encrypted content 708 from other locations.

[0135] DRM bureau services based upon distributed DRM systems are quitedifferent from the clearing house services of client-side DRM systems.Client-side DRM systems store their rights at the point of consumption(i.e. the client-side) and are restricted to making rights managementdecisions at the point of consumption. On some intermittent basis thesedecisions are relayed on to a network-accessible clearing house wherethey form a part of a reactive audit trail, with publishers receivingroyalties based on audited usage.

[0136] In contrast, in this embodiment, the DRM bureau service storesthe rights on the bureau service's DRM servers and proactively servesrights in response to consumer demand. This proactive and centralisedcontrol over consumer's access rights offers several advantages overprevious reactive approaches. For example, the centralised bureauservice can implement rights management methods that use a centralisedview of consumer access patterns, e.g. restricting an organisation to apredetermined number of concurrent accesses to a content set (fromindividual consumers or groups, e.g. departments). As another example,the centralised bureau service can easily implement cross-consumer andcross-publisher rights management policies, e.g. providing access topreview music tracks from one publisher in exchange for subscribing to atext journal from another publisher. As another example, when rights arestored on the consumer device, there must be some mechanism to preventthese rights being copied from device to device (along with theDRM-encrypted content). This inevitably leads to the consumer beingforced to access DRM-protected content from a limited number of devices(usually one device). Storing the rights on a centralised bureau serviceDRM server, especially one that is accessible via the Internet forexample, enables consumers to access DRM-protected content fromwhichever computer or other device they choose, which is a feature thatis of rapidly increasing importance in an increasingly mobile world. Asyet another example, proactive serving of rights from a centralised DRMserver gives publishers immediate and continued control over theircontent, e.g. revoking rights from a specific consumer for a proactiveDRM solution is as simple as removing a record from a DRM serverdatabase. Reactive DRM solutions, where the rights are stored on theconsumer device, must typically wait until those rights expire accordingto their original terms.

[0137] Rights Bank

[0138]FIG. 8 illustrates schematically an example of a DRM bureau server801 operating as a “rights bank”. The “rights bank” service isparticularly useful for a consumer who wishes to access DRM-encryptedcontent to which she has the rights from more than one device, such as awork PC 802 and a home PC 804. When a consumer purchases the rights toaccess bureau DRM-protected content (or is granted those rights), therights are initially deposited in the consumer's bureau account 806.Before the consumer can access the relevant DRM-protected content, therights must travel to the point of consumption, i.e. the consumer device802 or 804, where the rights are interpreted by the DRM client (which isa software and/or hardware component, typically, executing within theconsumer's device 802 or 804). The DRM client can obtain the rights fromthe DRM server 801 at some time prior to accessing the content (e.g. atthe time of requested access, at the time of purchase of the rights,etc.). In one embodiment, the DRM server 801 retains active copies ofthe rights at the DRM server 801 when the rights are sent to the DRMclient. The rights are thus “checked out” (checked out rights beingdenoted in FIG. 8 by reference numeral 808) to the client for a periodof time (which can range from say seconds to forever). This activepersistence of rights on the DRM bureau server 801 makes the DRM bureauserver 801 effectively a “rights bank”.

[0139] The DRM bureau server 801 can be configured to limit the numberof consumer devices (for an individual consumer) to which these rightscan be checked out at any one time. This has the advantages thatpublishers have control over how many devices a particular consumer canuse to access their content and that, subject to publisher agreement,consumers can access DRM-protected content on multiple devices, e.g.work and home PCs.

[0140] Thus, a consumer's concerns about being restricted to a specificdevice (and, for fixed devices, a single location) are balanced againstthe publisher's concerns about possible abuse from consumers sharingauthentication details (e.g. a username and password used to identifythe consumer to the DRM client). With restrictions on the number ofdevices from which a consumer can access DRM-protected content, theconsumer will be less likely to share authentication details since theother consumers with whom they share their details will be able to “lockout” the original consumer from their content.

[0141] Furthermore, the likelihood of consumers losing access to rightsstored only locally on their consumer devices is in general high, forreasons ranging from forgetting their passwords to catastrophic failureof the client device. Making the consumer responsible for archival ofdisaster recovery of their rights will meet with stiff consumerresistance, especially if the DRM client makes recovery from archivesdifficult because of its attempts to protect those rights fromtampering. Retaining active copies of the consumer's rights on a bureauserver makes it possible for the consumer to recover her rights at anytime. The DRM system can support rights recovery directly, for examplevia the bureau Web site, and/or indirectly, for example via customersupport (perhaps in cases where the bureau needs to establish that therecovery is for legitimate reasons rather than an illicit attempt toobtain additional rights).

[0142] The so called “perpetuity problem” is one of the biggestobstacles to the widespread commercial consumption of digital contentand typically manifests itself in two ways. First, consumers areaccustomed to purchasing more traditional content formats (e.g., print,CD music, etc.) at a point in time and then being able to access thatcontent in perpetuity. In practice, “perpetuity” in such cases equatesto periods in the region of ten years, but the consumer perception is ofa need for literal perpetuity. Secondly, digital content formats areevolving at an extremely rapid pace (in terms of compression andquality, for example) and are designed for consumption on consumerdevices (principally computing devices) that are themselves alsoevolving at a similar pace. This rate of change of digital media formatsand computer-based consumer devices considerably reduces the feasibilityof delivering digital content with lifetimes comparable to moretraditional media formats.

[0143] So, on the one hand consumers want access to purchased content inperpetuity while on the other hand publishers wish to use DRM systems toprotect that content from unauthorised redistribution. This can beachieved utilising the bureau service not only as a centralised store ofrights but also as a means to apply or upgrade existing rights to olddigital content that has been updated to new media formats and/or fornew consumer devices.

[0144] It will be appreciated that the consumer desire for perpetuityaccess corresponds to a requirement to maintain their rights on bureauDRM servers in perpetuity, and preferably to have the option to havethose rights upgraded or updated as necessary. This in turn implies arequirement for someone to pay to maintain those rights on the DRMbureau servers until the consumer no longer requires access to them.

[0145] Embodiments of the DRM bureau can offer various revenuedetermination methods to address consumers'expectations of perpetuity.For example, the consumer can pay the DRM bureau a recurring fee(effectively a subscription) in order to “bank” their consumer rights.This fee can be regarded as covering the cost of a form of insurancethat protects the consumer against the accidental loss of rights,provides value-added features such as “rights roaming” as discussedlater, and provides a route to apply or upgrade existing rights to olddigital content updated to new media formats and new consumer devices.Alternatively or additionally, the publisher can pay the DRM bureau arecurring fee in order to maintain consumer rights on the DRM bureauservice and thereby improve their consumer experience. In practice, thisimplies that the consumers will themselves pay the publisher some formof recurring fee (which may be non-monetary, e.g. some “service-in-kind”such as accepting advertising).

[0146] Rights Boutique

[0147]FIG. 9 illustrates schematically an example of a DRM bureauservice operating as a “rights boutique”. Using the bureau, a publisher902 of content configures (optionally from pre-configured “off-the-shelfrights templates” 904 provided by the bureau) “rights templates” 906which can then be purchased by or granted to consumers as “rightsinstances” 908. The act of selling or granting rights to a consumerresults in a copy of a rights template being instantiated 908,associated with the consumer and/or consumer device(s) and/or associatedwith particular items of digital content and “deposited” in theconsumer's bureau account 912.

[0148] Since the rights template configuration forms are hosted on thebureau server 910 (typically accessible via a standard Web browser), thepublisher does not have to install any specialised hardware or softwareon their local computing devices. Configuring rights templates can rangefrom configuring templates from scratch to choosing from a selection ofpre-configured templates (with the ability to reconfigure theoff-the-shelf templates). The “off-the-shelf” templates may includebasic or common rights limitations (such as “no printing” or “print onceonly” or “no save allowed”) which can be tailored or adapted by apublisher according to need (e.g. to add an expiry time for a particularcustomer). In some embodiments, the DRM bureau optimises pre-configuredoff-the-shelf templates to suit different publishing market segments,e.g. music, legal, etc.

[0149] Person DRM-Encryption

[0150] Cryptographic techniques used by modern DRM systems areinherently symmetrical. That is, the algorithms used for encryption arelargely identical with those used for decryption (and signing forsignature verification). Thus, referring to FIG. 10, the hardware andsoftware used by the DRM client 1006 (installed on the consumer'sdevice) contains most if not all of the functionality required toDRM-encrypt content in the first place. As a result, the DRM bureauservice may be used for “personal DRM-encryption” to encrypt rawunencrypted content 1008 into DRM-encrypted content 1010. The bureauserver 1012 can manage the rights as discussed above.

[0151] In accordance with one embodiment, all the functionality requiredto DRM-encrypt content is included in the basic DRM client 1006, whilein other embodiments sufficient functionality is included in the basicDRM client 1006 such that remaining functionality 1004 can be downloadedon demand (e.g. using technologies such as Java or ActiveX). As aresult, every consumer that has been DRM-enabled in this way is aDRM-capable publisher when taken in conjunction with a full-service DRMbureau.

[0152] The DRM client-based encryption application is hereafter referredto as the DRM client encryptor. This application is especially powerfulif the DRM client can be activated within the context of the DRM bureau(e.g. within the pages of a Web-based DRM bureau, i.e. in-browser) sothat the operation of the DRM client encryptor is tied seamlessly tothat of the DRM bureau service (e.g. so that rights managementparameters configured on the bureau service, such as the name of acontent subset, can be handed transparently from the bureau servicedatabase to the DRM client encryptor).

[0153] Publishers using a DRM bureau service according to thisembodiment need only download and install one ubiquitous DRM client.They would generally want to do this in any case to be able to accessDRM-encrypted content for test purposes. If more sophisticatedDRM-encryption functionality is required (e.g. streaming encryption),the publisher can obtain additional toolkits (e.g. by download andinstallation) in addition to the basic DRM client. Unencrypted contentneed never leave the publisher's site. The content is encrypted in placeby the DRM client encryptor.

[0154] Furthermore, with every DRM-enabled consumer also being aDRM-capable publisher, opportunities are opened up for greater personalcontrol over personal information. (Control over personal informationhas previously been the preserve of centralised MIS departments, trustedthird parties, etc.). Being able to DRM-encrypt one's own content, issuerights to specified individuals and being able to revoke those rights,represents a big step forward in terms of personal privacy.

[0155] Pricing Methods

[0156] Pricing methods for a DRM bureau service are now discussed. FIGS.11A to 11C illustrate schematically examples of a load-based pricingmethod for a DRM bureau service. In general, the pricing methodsextended by a DRM bureau service to its users (i.e. publisher andconsumers of DRM-protected content) should at least cover the costs ofmaintaining the DRM bureau service infrastructure and make commercialsense to publishers and consumers. However, the derivation of anequitable pricing method for a DRM bureau service is complicated by thefact that some DRM-encrypted content may be subject to a consumer chargeand by the fact that some DRM-encrypted content may be free to consumersbut still subject to publisher control (e.g. rights expire after acertain period). Different commercial methods (e.g. subscription vs.metered vs. pay-per-use) can result in dramatically different loading onthe bureau DRM servers.

[0157] The issue of “perpetuity” is also one that may need to beconsidered. That is, whereas a physical book may effectively beconsidered to last forever there is no practical equivalent for digitalcontent given that the computing platform for which it is purchasedrequires continuous hardware and software updates, effectively renderingit obsolete within approximately five years.

[0158] In accordance with an embodiment of the invention then, aload-based pricing method is based upon three pricing axes. FIG. 11Aillustrates schematically one such axis, based upon the number of bureauconsumer accounts holding rights on the bureau DRM server pertaining toDRM-encrypted content from a given publisher (“maintained accounts”).FIG. 11B illustrates schematically an axis based upon the degree ofconsumer activity for content from a given publisher (“consumeractivity”). FIG. 11C illustrates schematically an axis based upon thevolume of rights being maintained per consumer for content from a givenpublisher (“rights volume”). In practice, the pricing method extended tobureau-registered publishers (and optionally bureau-registeredconsumers) may be a combination of one or more of these pricing axes.

[0159] Referring to FIG. 11A (maintained accounts), say once everybureau accounting period (for example every month), database queries arerun against the bureau DRM servers to effectively count the number ofbureau-registered consumers storing rights on the bureau DRM serverspertaining to content from each bureau-registered publisher. Publisher Xis then charged (by the bureau) in proportion to the number of consumersstoring rights to X's content on the DRM server. The exact relationshipbetween the number of consumers and the price charged to publisher X canbe tuned to market conditions, e.g. a straight price per consumer (FIG.11A-l), banded pricing for quantised “jumps” in the number of consumers(FIG. 11A-2), a curve (FIG. 11A-3), etc.

[0160]FIG. 11B illustrates schematically the pricing method based onconsumer activity. Say once every bureau accounting period (for exampleevery month), database queries are run against the bureau DRM serversthat effectively count the number of times each bureau-registeredconsumer (bureau consumer) “hit” the bureau DRM servers in order toaccess content from each bureau-registered publisher (bureau publisher).Each consumer “hitting” the DRM server for a given publisher's contentis added into a load category depending upon the number of hits withinthe accounting period. Any number of load categories may be employedbut, in accordance with one example embodiment shown in FIG. 11B-1, fourload categories are employed ranging from no hits to many hits. The fourload categories are:

[0161] (i) inactive—no load on bureau DRM servers for publisher X;

[0162] (ii) low use—relatively minimal load on bureau DRM servers forpublisher X;

[0163] (iii) medium use—relatively moderate load on bureau DRM serversfor publisher X; and,

[0164] (iv) high use—relatively considerable load on bureau DRM serversfor publisher X.

[0165] As indicated in FIG. 11B-2, each load category is associated witha fee for the duration of the bureau accounting period. The total pricefor each load category is therefore the number of accounts placed intoeach load category multiplied by the load category fee. The total pricefor publisher X is the sum of the totals from each load category. Theload category fees are calculated against the cost of the bureauinfrastructure and operational costs required to sustain these accountloads and are charged by the bureau service to the relevant publishers(in this case publisher X).

[0166] “Rights volume” accounting is now discussed with reference toFIG. 11C. Say once every bureau accounting period (for example, everymonth), database queries are run against the bureau DRM servers toeffectively meter the number of distinct rights being maintained by eachbureau-registered consumer for content from each bureau-registeredpublisher. For example, consumer Y's account may be maintaining therights for several distinct products from publisher X. This representsmore potential accesses to publisher X's content than a consumer withjust the rights to a single product and hence more value to thepublisher X.

[0167] The bureau calculates, across all bureau-registered consumers, acumulative metric of the volume of rights being maintained for publisherX's content. In some embodiments, since rights are continuously flowingin and out of the bureau DRM servers, the metric is calculated from thevolume of rights and the time those rights spend on the DRM bureauservers, giving rise to the concept of “rights days” or “rightsminutes”, etc. For example, in FIG. 11C-1, the volume may be calculatedby the area under the curve.

[0168] In the context of paid consumer access to bureau-protectedcontent, one charging method for the bureau is to retain a percentage ofeach purchase, e.g. if a bureau-registered consumer is charged $100 fora year's subscription to a financial research report the bureau couldretain, say, 15% or $15 and pass on an 85% or $85 royalty to thepublisher. In practice, however, this simplistic charging method may beperceived as inequitable by publishers of high value and low volumecontent who may be charged as much or more than low value and highvolume publishers despite causing minimal load to the bureau DRM servers(due to the low volumes).

[0169] In accordance with an embodiment of a pricing method, a moreequitable revenue-based bureau pricing method is employed, whereby thepercentage of revenue claimed by the bureau is calculated from a gridwhose axes are the value of the content and the volume of purchasetransactions. An example of such a grid 1201 is illustratedschematically in FIG. 12.

[0170] The y-axis 1202 of the grid 1201 represents purchased contentvalue, and the x-axis 1203 of the grid 1201 represents purchase volume.The stacks of coins in the grid 1201 represent relative revenuepercentages paid by the publishers in accordance with this pricingmethod embodiment. For example, high volume publishers pay the bureauthe smallest percentage of their revenue relative to publishers with thesame purchased content value (since they may justifiably claim adiscount over lower value and lower volume publishers). Low value, lowvolume publishers pay the bureau the greatest percentage of theirrevenue (since they represent the least value to the bureau and take theleast advantage of the bureau's in-built economies of scale). Low valuebut high volume publishers pay the bureau intermediate percentages ofrevenues since the bureau can take advantage of its in-built economiesof scale to limit the cost of supporting these revenue volumes. Finally,high value but low volume publishers pay the bureau intermediatepercentages of revenues since they represent minimal load on the DRMservers. To simplify the calculations, the formula for percentage ofrevenue may be based on discrete bands of values for published contentvalue and purchase volume rather than continuous values.

[0171] It is recognised that some publishers may charge consumers in anindirect fashion (e.g. via an “offline” subscription) while maintaininga nominal charge via the bureau. For this and other reasons, the DAMbureau can impose a load-based floor to the revenue-based pricingmethod, as illustrated schematically in FIG. 13. According to thispricing method, if the publisher fee due to the bureau service ascalculated from the load-based pricing method exceeds the fee calculatedfrom the revenue-based pricing method (taking into account the durationof purchased rights), then the load-based fee takes precedence. In theFIG. 13 example, in May, June, July and August the publisher fee due tothe bureau service as calculated from the load-based pricing methodexceeds the fee calculated from the revenue-based pricing method. Thus,in these months, the load-based pricing method takes precedence. Theload-based pricing floor avoids the pathological situation where thebureau does not generate sufficient revenues to cover its infrastructureand operational costs.

[0172] Bureau Affiliate Programme

[0173]FIG. 14 illustrates schematically a logging-based bureau affiliateprogramme. Basically, client-side logging information 1405 is sent fromthe DRM clients 1402 (on remote consumer devices) to the bureau server1401 for consolidation into a centralised bureau DRM audit trail 1403.Specifically, each participating DRM client 1402 records the “location”from which a given consumer accesses DRM-protected content. This may be,for example, a location on a computer's local file system, a sharednetwork drive, a Web server on the Internet or a corporate intranet,etc.

[0174] DRM clients can log a number of important “locations”, includingfor example REF 1404, the location of the prior content that led, linkedor referred to the current content; LOC 1406, the location of thecurrent content; and, TO 1408, the location of the next content to whichthe consumer goes from the current content.

[0175] This information is then used by the bureau 1101 to operate anaffiliate program 1410 whereby affiliate partners are rewarded(financially or otherwise) for one or more of: linking to DRM-encryptedcontent (derived from the REF record 1404); hosting DRM-encryptedcontent (derived from the LOC record 1406); and, linking fromDRM-encrypted content (derived from the TO record 1408).

[0176] Advantages of such an affiliate program 1410, enabled by theunique capabilities of the DRM client to provide feedback on downstreamconsumption of digital content, include for example: providingpublishers with an auditable mechanism for giving partners incentives tohost, distribute and link to the publisher's content; and, providingconventional retail channels with new, meaningful and commerciallyviable roles in the digital publishing future (whereas digitalpublishing has typically been viewed as a threat to conventional retailoperations).

[0177] Plural DRM Bureaux

[0178] After DRM technologies and DRM-based bureau services are widelyadopted, it is expected that there will soon be a number of DRM bureauservices distributed throughout the world, for example because theoriginal DRM bureau service has been franchised to third parties so thatit may be specialised for horizontal market segments (e.g. languagegroupings) or vertical market segments (such as specific media types orapplications). In the short term, in order to consume content fromdifferent publishers, when those publishers are served by different DRMbureau services, the consumer will need to hold a separate consumeraccount with each bureau service. This is inconvenient since theconsumer needs to authenticate herself to multiple bureaux (and wouldtherefore typically need to manage multiple usernames and passwords) andreceives separate statements and bills from each bureau.

[0179]FIG. 15 illustrates schematically a system of plural DRM bureaux(only two DRM bureaux 1502 and 1504 being shown for simplicity),connected by a “gateway” 1506 via which a subscriber to one DRM bureaucan access content whose rights are controlled by another bureau. Thus,the client-side DRM software is capable of interoperating with the DRMservers behind each of the disparate bureau services.

[0180] Furthermore, a primary consumer account can “roam” betweenbureaux in much the same way that a mobile telephone user can roaminternationally, i.e. the user can consume content managed by otherbureaux with which a primary bureau has established cross-chargingrelationships, authenticating themselves to the primary bureau accountvia the other bureau and receiving consolidated statements and billsfrom the primary bureau.

[0181] Embodiments of the present invention have been described withparticular reference to the examples illustrated. However, it will beappreciated that variations and modifications may be made to theexamples described within the scope of the present invention.Furthermore, the claims that follow relate entirely or principally tosystems (i.e. typically apparatus). It will be appreciated thatcorresponding methods are also within the scope of the presentinvention.

1. A system for managing a consumer's access to content to be renderedby a DRM client of the consumer, the system comprising: a DRM server forengaging in a transaction with a consumer DRM client such that thetransaction results in the consumer being granted at least one right tothe content, the DRM server being arranged such that the at least oneright is stored at the DRM server and the DRM server checks out a copyof the at least one right to a said consumer DRM client.
 2. A systemaccording to claim 1, wherein the DRM server includes a storage deviceand is arranged to store the at least one right in the storage deviceand to allow the at least one right to reside in the storage device fora predetermined time before being made void.
 3. A system according toclaim 2, wherein the DRM server is arranged to void the at least oneright by removing the at least one right from the storage device.
 4. Asystem according to any of claims 1 to 3, wherein the DRM server isarranged so that the copy of the at least one right checked out to asaid consumer DRM client is not identical to the at least one rightstored on the DRM server.
 5. A system according to any of claims 1 to 4,wherein the DRM server is arranged to check out a further copy of the atleast one right to a said consumer DRM client in the event that the oran earlier copy of said at least one right is lost or otherwiseinaccessible to a said consumer DRM client.
 6. A system for managing aconsumer's access to content to be rendered on a consumer contentrendering device, the consumer content rendering device including astorage device, and wherein a DRM server is arranged to provide a copyof at least one right to the consumer content rendering device forstorage in the storage device, the system comprising: a DRM client on aconsumer content rendering device that is arranged to attempt initiallyto retrieve a copy of at least one right from a storage device of theconsumer content rendering device, and, in the event that a copy of theat least one right is not found in the storage device, to attempt toretrieve a copy of the at least one right from a said DRM server.
 7. Asystem according to claim 6, wherein the DRM client is arranged to allowa copy of the at least one right to reside in the storage device for apredetermined time before being made void.
 8. A system according toclaim 7, wherein the DRM client is arranged to void the at least oneright by removing the copy of the at least one right from the storagedevice.
 9. A system according to claim 7 or claim 8, wherein the DRMclient is arranged to allow the consumer to configure the predeterminedtime.
 10. A system for making rights management decisions relating toaccess to content, the system comprising: a DRM server for making afirst rights management decision based on a request from a DRM clientfor a right to access content and for responding to the requestaccordingly such that a said DRM client can make a second rightsmanagement decision based on the response from the DRM server.
 11. Asystem according to claim 10, wherein the DRM server is arranged so thatthe first rights management decision includes the DRM server refusing togrant a said DRM client the right to access the content on the basisthat granting the right would cause a concurrent consumer limit to beexceeded.
 12. A system according to claim 10 or claim 11, wherein theDRM server is arranged so that the first distributed rights managementdecision includes granting the right to access the content on aplurality of devices.
 13. A system according to any of claims 10 to 12,wherein the DRM server is arranged so that the first distributed rightsmanagement decision includes limiting the number of devices that can beused to access the content.
 14. A system according to any of claims 10to 13, wherein the DRM server is arranged to modify at least oneindividual right specification based upon at least one item of consumerinformation received from a DRM client.
 15. A system according to any ofclaims 10 to 14, wherein the DRM server is arranged to store a groupright specification for at least one consumer of a group of consumersand to make a rights management decision based on the group rightspecification.
 16. A system according to any of claims 10 to 15, whereinthe DRM server is arranged to modify at least one individual rightspecification associated with a first publisher based upon at least onetransaction associated with a second publisher.
 17. A system for makingrights management decisions for content, the system comprising: a DRMclient that is arranged to request from a DRM server a right to accesscontent and to receive from a said DRM server the result of a firstrights management decision made at the DRM server, the DRM clientfurther being arranged to make a second rights management decision basedon a said result received from a said DRM server.
 18. A system accordingto claim 17, wherein the DRM client is arranged so that the secondrights management decision includes determining whether the DRM clienthas a right to print the content.
 19. A system according to claim 17 orclaim 18, wherein the DRM client is arranged so that the second rightsmanagement decision includes determining whether the DRM client has aright to save the content to a storage device.
 20. A system for loggingaccess to content by one or more consumers, the system comprising: a DRMserver that is arranged to log requests for access to content to producea first log record and to receive from at least one DRM client a secondlog record of access to the content.
 21. A system according to claim 20,wherein the DRM server is arranged to merge the first log record and thesecond log record.
 22. A consumer DRM client arranged to log access tocontent by the DRM client to produce a log record, the DRM clientfurther being arranged to transmit the log record to a DRM server.
 23. ADRM client according to claim 22, wherein the DRM client is arranged totemporarily cache the log record and to send the log record to a saidDRM server after a predetermined period of time.
 24. A system forobtaining from a DRM server a right to access content on a consumerdevice, the right to access the content being stored in both theconsumer device and the DRM server, the system comprising: a DRM client;and, a consumer device with which the DRM client is associated; the DRMclient being arranged first to attempt to retrieve the right from theconsumer device and then, if unable to retrieve the right from theconsumer device, to attempt to retrieve the right from a said DRMserver.
 25. A system according to claim 24, wherein the consumer devicehas both persistent storage and non-persistent storage, the DRM clientbeing arranged to attempt to retrieve the right in the following order:from the non-persistent storage of the consumer device, and then, if theright cannot be retrieved from the non-persistent storage of theconsumer device, from the persistent storage of the consumer device, andthen, if the right cannot be retrieved from the persistent storage ofthe consumer device, from a said DRM server.
 26. A system for managingrights to content, the system comprising: a DRM server that is arrangedto handle rights management on behalf of a plurality of contentpublishers and to issue rights to one or more consumers accordingly. 27.A system according to claim 26, wherein the DRM server is arranged toparticipate in rights management decisions in cooperation with aclient-side DRM system.
 28. A system according to claim 26 or claim 27,wherein the DRM server is arranged to issue rights to DRM-protectedcontent without which access to the said DRM-protected content isprecluded.
 29. A system according to any of claims 26 to 28, wherein theDRM server is arranged to maintain accounts for consumers into which theplurality of content publishers can deposit consumer-specific rights.30. A system according to any of claims 26 to 29, wherein the DRM serveris arranged to require that a consumer provide a consumer identificationin order to download a right to access content.
 31. A system accordingto any of claims 26 to 30, wherein the DRM server is arranged toimplement cross-consumer rights management policies.
 32. A systemaccording to any of claims 26 to 31, wherein the DRM server is arrangedto implement cross-publisher rights management policies.
 33. A systemaccording to any of claims 26 to 32, wherein the DRM server is arrangedto permit at least one consumer to roam between at least two consumerdevices and to ensure that said at least one consumer can onlysimultaneously access the content on a limited number of the at leasttwo consumer devices.
 34. A system according to any of claims 26 to 33,wherein the DRM server is arranged to deliver a copy of a right to aconsumer whilst retaining a copy of the right in storage.
 35. A systemfor providing rights to content to consumers, the system comprising: aserver that is arranged to provide a network-accessible interface thatis arranged to enable publishers of content to create and configurerights templates that can be subsequently purchased by or granted toconsumers as rights instances.
 36. A system according to claim 35,wherein the server is arranged to provide consumer accounts in which therights instances can be stored.
 37. A system for providing rights tocontent to consumers, the system comprising: a DRM server that isarranged to calculate a charge for a publisher based upon the number ofconsumers holding rights to content from the publisher on the DRMserver.
 38. A system according to claim 37, wherein the DRM server isarranged to redetermine the charge at predetermined intervals.
 39. Asystem for providing rights to content of a publisher to consumers, thesystem comprising: a DRM server that is arranged to calculate a chargefor a publisher based upon the loading imposed on the DRM server byconsumers holding the rights to content of said publisher.
 40. A systemaccording to claim 39, wherein the charge is based on the number ofindividual accesses to the DRM server resulting from the consumersaccessing content of said publisher.
 41. A system for providing rightsto content of a publisher to consumers, the system comprising: a DRMserver that is arranged to calculate a charge for a publisher based uponthe volume of the rights maintained on the DRM server on behalf ofconsumers holding the rights to content of the publisher.
 42. A systemaccording to claim 41, wherein the volume of he rights is determined inaccordance with the time that he DRM server holds said rights.
 43. Asystem for providing rights to content of a publisher to consumers, thesystem comprising: a DRM server that is arranged to calculate a chargefor a publisher based upon a percentage of the value of rightsassociated with content produced by the publisher and maintained by theDRM server.
 44. A DRM client for obtaining access rights to DRMencrypted content and decrypting the content, the DRM client also beingcapable of encrypting content.
 45. A DRM client according to claim 44,wherein the DRM client is capable of adding a digital signature tocontent encrypted by the DRM client.
 46. In combination, at least twoDRM servers with a gateway therebetween, wherein one of the DRM serversis arranged to hold an account on behalf of a consumer and to allow saidconsumer to access DRM-protected content whose rights are controlled bythe other of said DRM servers via the gateway.
 47. A combinationaccording to claim 46, wherein the gateway between the at least two DRMservers is operated subject to cross-charging relationships between theoperators of the DRM servers.
 48. A combination according to claim 46 orclaim 47, wherein the one of the DRM servers that holds an account for aconsumer is arranged to forward consolidated usage reports, consolidatedstatements and consolidated billing to said consumer based on totalaccess to the DRM servers by the consumer.